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(57) ABSTRACT 

An access server and a DSLAM are continuously connected 
by a PVC. The access server and the DSLAM manage an 
unused ATM VC within the PVC while making a commu- 
nication with an idle VC indication cell which is an OAM 
cell. The DSLAM allocates the unused ATM VC by com- 
municating with the access server based on a call originating 
request issued from a modem. 
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SVC ACCESSING METHOD FOR USE IN 
ATM-DSLAM 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to a network accessing 
technique based on an ATM (Asynchronous Transfer Mode) 
technique and a DSL (Digital Subscriber Line) technique. 

2. Description of the Related Art 

With the rapid popularization of the Internet, the demand 
for quickly interconnecting end users and the Internet has 
been increasing. 

FIG. 1 is a block diagram showing the configuration of a 
typical system for accessing the Internet. 

An Internet backbone 2101 is directly connected with 
Web sites 2102, ftp sites 2103, enterprise LANs (Local Area 
Networks) 2104 with dedicated lines, and access points 
2105 operated by Internet Service Providers (hereinafter 
referred to as ISPs). 

Each general user (home user) or each user 2107 in a 
small enterprise makes a connection to a desired site via the 
Internet backbone 2101 by accessing an access point 2105 
from a PC (Personal Computer) or a LAN via an access 
network 2106. 

Since the Internet backbone 2101 and the access point 
2105 are normally interconnected with a high-speed dedi- 
cated digital line, a fast access is ensured. In the meantime, 
the access network 2106 linking a user 2107 and an access 
point 2105 is typically a low-speed network such as a public 
telephone network, an ISDN (Integrated Services Digital 
Network), etc. in many cases, although a dedicated digital 
line network may be sometimes used. 

However, it has become difficult for such a low-speed 
network to meet the rapidly increasing demand for the 
Internet in recent years. Especially, as a SOHO (Small 
Office/Home Office) becomes popular, the demand for 
quickly connecting a small-scale LAN to the Internet has 
been increasing. 

Introduction of a new high-speed line infrastructure such 
as an optical fiber, etc. is a final solution in order to meet 
such demands. However, since this requires a lot of equip- 
ment investment, labor and time, it can hardly become a 
practical and short-term solution. 

As a viable alternative, the DSL (Digital Subscriber Line) 
technique attracts public attention as a high-speed commu- 
nications technique which uses telephone copper wire cables 
currently arranged in most homes and enterprises as they are 
and can coexist with communications using existing tele- 
phones. 

The DSL technique is one type of modem technique. This 
technique includes methods such as an ADSL (Asymmetric 
DSL), an SDSL (Symmetric DSL), an HDSL (High bit rate 
DSL), a VDSL (Very high bit rate DSL), etc., which were 
developed for supporting various transmission rates, a 
symmetric/asymmetric communication, a modulation/ 
demodulation method type, etc. These methods are generally 
referred to as an xDSL. The general term "xDSL" is here- 
inafter used in this specification. 

With the xDSL technique, xDSL modems are arranged at 
both ends of an existing copper wire cable which links a 
subscriber home and an accommodation station of a com- 
mon carrier. As a modulation/demodulation method in this 
case, any of three methods such as a 2B1Q (2 Binary 1 
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2 

Quaternary), a CAP (Carrier-less Amplitude/Phase 
modulation), and a DMT (Discrete Multi-Tone) is adopted. 
With any of these modulation/demodulation methods, a 
high-speed communication of several-hundred to several- 

5 mega bits per second is made over a high-frequency band of 
approximately 30 KHz to 1 MHz. 

As described above, the frequency bandwidth used in an 
xDSL communication differs from that of approximately 50 
Hz to 4 KHz, which is used by a telephone speech signal. In 

10 such a case, a telephone speech signal and an xDSL signal 
can be multiplexed on one subscriber line by connecting 
circuits for different frequencies, which are referred to as 
splitters, to both of the xDLS modems within the subscriber 
home and within the common carrier. That is, in the sub- 
scriber home, the telephone and the xDSL modem are 

15 connected to the subscriber line via the splitter within the 
subscriber home. In the meantime, in the accommodation 
station, the existing telephone switch and the XDSL modem 
are connected to the subscriber line via a splitter within the 
accommodation station. 

20 A collective modem which has a multiplexing capability 
and is referred to as a DSLAM (DSL Access Multiplexer) is 
mainly used as the xDSL modem within the accommodation 
station. With the DSLAM, xDSL signals from a plurality of 
xDSL lines are terminated by respective modem circuits, 

25 and the respectively terminated xDSL signals are multi- 
plexed by a high-speed backbone interface. Use of such a 
DSLAM allows an xDSL line to be employed as a low-cost 
and high-speed access line leading to each type of backbone. 
The above described backbone includes a dedicated line 

30 network, which is connected via a high-speed dedicated 
digital line interface and links headquarters and branch 
offices within an enterprise, the Internet connected via a 
LAN and a router, an ATM (Asynchronous Transfer Mode) 
network connected via an ATM interface such as a SONET 

35 interface, etc. 

The technique for using the DSLAM as the front end of 
the ATM network among the above described techniques is 
expected to be a promising technique for implementing an 
ATM service on a global scale where common carriers tend 
to utilize a basic trunk line system in an ATM form. 
Furthermore, the ATM network is anticipated as a network 
for implementing the Internet backbone 2101 and the access 
network 2106, which are shown in FIG. 1. Considering this 
fact and the convenience where an existing copper wire 
cable can be used while maintaining a telephone service, it 
is significant that the xDSL line accommodated by the 
DSLAM is used as an access line to the ATM network or to 
the Internet. 

5Q In this case, an IP datagram transmitted, for example, 
from the PC or the LAN possessed by the user 2107 to the 
Web site 2102, is converted into an ATM cell and is further 
converted into an XDSL signal by the XDSL modem in the 
user 2107's home. 

55 The xDSL signal is transmitted to the copper wire cable 
which is the subscriber line via the splitter in the user 2107 's 
home, and reaches the accommodation station. 

After the xDSL signal is split from a telephone speech 
signal by the splitter in the accommodation station, it is 

60 received by the DSLAM within the accommodation station. 
The ATM cell received by the DSLAM is multiplexed 
with an ATM cell received from another subscriber line, and 
then transmitted to an ATM interface (such as a SONET 
interface) leading to the access network 2106 configured by 

65 the ATM network. 

The ATM cell which has passed through the access 
network 2106 is received by an access server within the 
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access point 2105. The access server extracts the IP data- form where the connection resources within an ATM net- 
gram from the received ATM cell. work can be efficiently used, when an xDSL line is con- 

The extracted IP datagram is transferred to the Web site nected to a particular destination such as an access server, 

2102 via the Internet backbone 2101. etc. via a cell switching network such as an ATM network, 

To typically implement the connection to the Internet, the 5 etc. 

user 2107 first makes a point-to-point connection to the 0 ne mode of the present invention assumes a method with 

access server within the access point 2105 which is the entry which a subscriber side modem which forrns modulation/ 

to the Internet backbone 2101 by usmg a protocol referred demodu i ation ^ a ^1 subs criber line method accesses 

to as a PPP (Point to Point Protocol). At this time, the user * j * A ™. . _ , , 

2107 is assigned a global IP address which is determined 10 an aCC ?^f ™ r ™°f*«> £ *™ sw f h network by 

according to a protocol referred to as an IP (Internet using ^TM cells transferred with an asynchronous transfer 

Protocol) and can be uniquely identified on the Internet, mode method via an accommodation station side modem, 

from a DHCP (Dynamic Host Configuration Protocol) which accommodates a digital subscriber Une to which the 

server etc. belonging to an access server depending on need. subscriber Slde modern is connected. 

Thereafter, the user 2107 stores the IP datagram including 5 Th Q access server and the accommodation side modem 

the IP address of an opposing server in a PPP packet by using are continuously connected by a permanent virtual connec- 

a global IP address which is originally possessed by the user tl0n - 

2107 or is dynamically assigned, and exchanges the IP Next, a virtual connection which is unused within the 

datagram with a server at a destination side. permanent virtual connection is managed in the access 

In the meantime, for example, if two communicating 2 o SCTVtr an< * tne accommodation station side modem, 

devices make a communication in an ATM network, ATM The accommodation station side modem communicates 

addresses must be respectively assigned to both of the with the access server based on a call originating request 

devices. At the same time, an ATM connection (VC: Virtual issued from the subscriber side modem, so that the unused 

Connection/Channel) which can be uniquely identified virtual connection is allocated to the subscriber side modem, 

within the ATM network must be established between the 25 According to the present invention, a PVC is established 

two devices. beforehand between an accommodation station side termi- 

Accordingly, with the technique for integrating the xDSL nating device (modem) and an access server. The accom- 

line, the ATM network, and the Internet, an ATM connection modation station side terminating device (modem) makes a 

must be established based on the specification of ATM communication with the access server based on the call 

addresses between the xDSL modem within the user 2107 30 originating request issued from the subscriber side termi- 

and the access server within the access point 2105 when a nating device (modem), so that an unused virtual connection 

PPP session is started, as described above. ^ allocated to the subscriber side terminating device. As a 

However, since the xDSL technique assumes that a high- result, the accommodation station side terminating device 

speed communication is made at a low cost by directly (modem) and the access server are continuously connected 

linking an XDSL mode within a subscriber home and a 35 by the above described PVC, whereby the connection 

DSLAM within an accommodation station, there is no resources can be significantly reduced, a connection control 

concept of connecting/disconnecting an xDSL communica- can be dramatically simplified, and the response perfor- 

tion for each communication. Therefore, this technique does mance can be improved in comparison with the case where 

not work well with the control for establishing/releasing an the accommodation station side terminating device and the 

ATM connection. 40 access server are connected for each call. 

Accordingly, a dedicated line connection form where the Additionally, according to the present invention, the con- 
access server within the access point 2105, the DSLAM trol for establishing/releasing a virtual connection within the 
within the accommodation station,, and the xDSL modem in PVC can be eflBciently performed by using management and 
the subscriber home are continuously connected with a PVC maintenance broadcast cells. 

(Permanent Virtual Connection/Channel) was convention- 45 Furthermore> according to the present invention, the 

ally adopted in the network system where the xDSL line, the operation/non-operation of the accommodation station side 

ATM network, and the Internet are integrated. modem can be controlled according to the operation/non- 

However, the same number of ATM connections as that of operation of the subscriber side modem, thereby preventing 

users 2107 are required in the above described conventional a was te of electric power when no communication is made, 

connection form, although general end users such as home 50 sm according t0 the present invention) a line can 

users etc. are not continuously connected to the Internet. be disconne cted even if a link is disconnected without a 

Therefore the connection resources (more specifically, the proper ss such ^ a ^ for powering down a 

number of VPIs/VCIs or the bandwidth used by a switch) modem or a PC 
within the ATM network are fixedly and wastefully used, 

which leads to the inability of ATM networks being applied 55 BRIEF DESCRIPTION OF THE DRAWINGS 

to a large number of subscribers. ~ ^ , . , t 

* ™ • , * , ^ * ^ . ,™ ,v , . . . One skilled in the art can easily understand additional 

An SVC (Switched Virtual Connection/Channel) which is features and objects of me ( &Qm ^ 

a connection for each call may be apphed to overcome this description of the preferred embodime nt and some of the 

prob em. However, because the connection form of the atUched drawings> k which: 

xDSL communication is assumed to be connectionless as 60 „.„ , „ . 

described above, this communication does not work well * 15 a block dl *& a T m t showiD S configuration of a 

with a connectionless SVC communication and an effective System for accessin g the Interaet i 

SVC controlling method does not currently exist. FIG " 2 15 a block diagram showing the configuration of a 

network system according to a preferred embodiment of the 

SUMMARY OF THE INVENTION 65 present invention; 

The present invention was developed in the above FIG. 3 shows communications protocol stacks between 

described background, and aims at realizing a connection respective devices; 
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FIGS. 4(a) through 4(f) show the data formats of the 
communications protocol stack in a PC 106; 

FIGS. 5(a) through 5(e) show the data formats of a 
communications protocol stack in a modem 101 on an IP 
tunnel side; 

FIGS. 6(a) through 6(c) show the data formats of a 
communications protocol stack in the modem 101 on an 
ATM side; 

FIGS. 7(a) through 1(d) show the data formats of a 
communications protocol stack in an access server 104; 

FIG, 8 shows the configuration of the modem 101; 

FIG. 9 shows the configuration of a DSLAM 102; 

FIG. 10 shows the configuration of the access server 104; 

FIG. 11 shows the data structure of an OAM cell; 

FIG. 12 shows the data structure of a nominated VC map; 

FIG. 13 shows the sequence for establishing an end-to- 
end connection; 

FIG. 14 shows the sequence for connecting an IP tunnel 
and an ATM VC; 

FIG. 15 shows the data format of a start control connec- 
tion request; 

FIG. 16 shows the data format of a start control connec- 
tion reply; 

FIG. 17 shows the data format of SetLinklnfo; 

FIG, 18 shows the data format of an outgoing call request; 

FIG. 19 shows the data format of an outgoing call reply; 

FIG. 20 shows a control cell list (No. 1); and 

FIG. 21 shows a control cell list (No. 2). 

DESCRIPTION OF THE PREFERRED 
EMBODIMENT 

Provided below is the explanation about the details of a 
preferred embodiment according to the present invention by 
referring to the drawings. 

<System Configuration of a Preferred Embodiment Accord- 
ing to the Present Invention> 

FIG. 2 is block diagram showing the configuration of a 
network system according to a preferred embodiment of the 
present invention. 

A modem 101 is an xDSL modem. One or more PCs 106 
are connected to the modem 101 via lOBase-T interfaces. 

The modem 101 and a DSLAM 102 are connected by a 
copper wire cable which is an existing subscriber line. 

Further, a splitter may be respectively arranged within a 
subscriber home and an accommodation station between the 
modem 101 and the DSLAM 102,. 

ATM switches 103, an ATM switch 103 and a DSLAM 
102, an ATM switch 103 and an ISP (Internet Service 
Provider) side access server 104, an ATM switch 103 and an 
access server 117, etc. are respectively interconnected by 
SONET interfaces. 

The ISP side access server 104 is connected to an Internet 
105 belonging to the corresponding ISP. Web sites 107 or 
another access server 108 which accommodates a LAN 109 
to which PCs 110 are connected is connected to the Internet 
105. An IP communication using an IP datagram is made on 
the Internet 105. 

The DSLAM 102 may be connected with a LAN 112 
which accommodates PCs 113, etc. via a DSU (Data Service 
Unit) 111 in addition to the modem 101. In this case, the 
DSLAM 102 and the DSU 111 are continuously connected. 

The DSLAM 102 may be connected with an access server 
114 which supports an xDSL communication, and the access 
server 114 may further be connected with a LAN 115 which 
accommodates PCs 116. 
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Additionally, an ATM switch 103 may be connected with 
an access server 117 to which an in-house LAN 118 which 
accommodates PCs 119 is connected. 
Communications Protocol Stacks Between Respective 
5 Devices> 

FIG. 3 shows the communications protocol stacks 
between respective devices configuring the network shown 
in FIG. 2. 

Provided first is the explanation about a communication 
protocol between a PC 106 and a modem 101 by taking as 
an example the case where data is transferred from the PC 
106 to the modem 101 with reference to FIGS. 3 through 5. 
Note that the communications protocol is the same also in 
the case where data is transferred from the modem 101 to the 
PC 106, except for the difference that the flow of the data 

15 becomes reversed. 

User information (such as TCP (Transfer Control 
Protocol) segment data, etc.) generated by an application 
within the PC 106 is stored in a data area of the IP datagram 
where a public IP address is specified in its header, as shown 

20 in FIG. 4(a). The public IP address can be uniquely identi- 
fied in the Internet space around the world. As will be 
described later, the IP address assigned to the IP datagram is 
identified by the ISP side access server 104 (simply referred 
to as an access server 104 hereinafter), so that the IP 

25 datagram is transferred, for example, to a Web site 107 on 
the Internet 105 shown in FIG. 2. 

Next, the IP datagram is stored in the data area of a PPP 
packet to which a header and a trailer are added, as shown 
in FIG. 4(6). After the PPP packet is identified by the modem 

30 101, it is terminated by the access server 104, as will be 
described later. With this packet, a point-to-point data com- 
munication between the PC 106 and the access server 104 
can be made via the modem 101. 

The PPP packet is then stored in the data area of the PPP 

35 packet generated based on a PPTP (Point to Point Tunneling 
Protocol) or an L2TP (Layer 2 Tunneling Protocol) as shown 
in FIG. 4(c). This PPTP (or L2TP) packet is terminated by 
the modem 101 as will be described later. The PPTP (or the 
L2TP) is a protocol for relaying a PPP packet to a second 

40 device whose line is connected to a first device so that the 
first device which is not directly connected to a line com- 
municates with a PPP connection destination which is reach- 
able via a line. In this case, the PPTP (or L2TP) packet 
including the PPP packet is made to pass through a logical 

45 communication channel between the first and second 
devices. In the preferred embodiment of the present 
invention, the PPTP (or L2TP) packet generated by the PC 
106 which is not directly connected to an xDSL line is 
transmitted to the modem 101 through the tunnel of a private 

50 IP communication channel to be described next. The modem 
101 extracts the PPP packet from the PPTP (or L2TP) 
packet, and transmits the extracted packet to the xDSL line 
leading to the access server 104 which is a PPP connection 
destination. The reason why the PPP packet is included in 

55 the PPTP (or L2TP) packet is to allow a plurality of sessions 
to be processed without inconsistency. To implement this, an 
identifier for identifying each session or a sequence number, 
etc. is stored in the header of the PPTP (or L2TP) packet. 
Next, in the PC 106, the PPTP (or L2TP) packet is stored 

60 in the data area of a UDP datagram generated based on a 
UDP (User Datagram Protocol) as shown in FIG. 4(d). The 
UDP datagram is terminated by the modem 101 as will be 
described later. A port number for identifying a PPTP (or 
L2TP) driver application which processes a PPTP (or L2TP) 

65 packet is assigned to the header of the UDP datagram. 

Additionally, in the PC 106, the UDP datagram is stored 
in the data area of the IP datagram where an IP address in 



09/14/2004, EAST Version: 1-4.1 



us 6,5: 

7 

private IP addresses which assigned for the local network 
between the PC 106 and the modem 101 is assigned to its 
header, as shown in FIG. 4(e). Even if a user who possesses 
the modem 101 can assign, for example, only one public IP 
address with the private IP datagram, the device (PC 106) 
within the LAN, to which the modem 101 is connected, can 
make an intercommunication in a local address space. 

Lastly, in the PC 106, the private IP datagram is stored in 
the data area of an Ethernet frame generated based on an 
MAC (Media Access Control) protocol as shown in FIG. 
4(f) y and is transmitted to a lOBase-T interface. The physical 
address of either of the devices between which a commu- 
nication is made is specified in the header of the Ethernet 
frame. With this frame, the control for preventing a frame 
collision in the lOBase-T interface is performed. 

After the Ethernet frame transmitted to the lOBase-T 
interface in the above described way is received by the 
modem 101, the private IP datagram is extracted from its 
data area as shown in FIGS. 5(e) and 5(d). 

Next, in the modem 101, the UDP datagram is extracted 
from the data area of the private IP datagram as shown in 
FIG. 5(c). 

Then, in the modem 101, a PPTP (or L2TP) driver 
application is invoked based on the port number assigned to 
the header of the UDP datagram, so that the PPTP (or L2TP) 
packet is extracted from the data area of the UDP datagram 
by the invoked driver as shown in FIG. 5(b). 

Furthermore, in the modem 101, the PPP packet is 
extracted from the data area of the PPTP (L2TP) packet after 
the PPP session is identified based on the information 
assigned to the header of the packet, as shown in FIG. 5(a). 

Provided next is the explanation about the communica- 
tions protocol between the modem 101 and the access server 
104 by taking as an example the case where data is trans- 
ferred from the modem 101 to the access server 104 with 
reference to FIGS. 3, 6, and 7. The communications protocol 
is the same also in the case where data is transferred from the 
access server 104 to the modem 101, except for the differ- 
ence that the flow of the data becomes reversed. 

The modem 101 stores the PPP packet received from the 
PC 106 in the data area of an AAL 5 (ATM Adaption Layer 
5) protocol data unit unchanged without further extracting 
the public IP datagram (refer to FIG. 4(a)) from the PPP 
packet, as shown in FIGS. 6(a) and 6(b). The AAL5 protocol 
data unit includes a CRC (Cyclic Redundancy Check) code 
for correcting data in its trailer. 

The modem 101 then stores the AAL5 protocol data unit 
in the payload of one or more ATM cells as shown in FIG. 
6(c). The algorithm for determining an ATM cell connection 
particularly relates to the present invention. This will be 
described later. 

Lastly, the modem 101 modulates the data stream of the 
ATM cells to an xDSL signal, and transmits the modulated 
signal to a subscriber line. 

The xDSL signal transmitted to the subscriber line in the 
above described way is received by the DSLAM 102 shown 
in FIG. 2. 

The DSLAM 102 extracts the ATM cells by demodulating 
the xDSL signal received from the subscriber line. 

After the DSLAM 102 converts the connection informa- 
tion included in the header of the ATM cells, it transmits the 
ATM cells to a SONET interface which uses an optical fiber 
as a physical medium (PHY), as they are, without extracting 
the user information from the ATM cells. More precisely, the 
format of the SONET signal is assembled from the ATM 
cells. 

The ATM cells transmitted to the SONET interface in this 
way are made to pass through the SONET interface by being 
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switched by one or more ATM switches 103 (shown in FIG. 
2) in an ATM cell level. 

Upon receipt of one or more ATM cells from the SONET 
interface (PHY), the access server 104 extracts the AAL5 
5 protocol data unit from the data area of each of the ATM 
cells and assembles the extracted units, as shown in FIGS. 
1(d) and 7(c). 

The access server 104 then extracts the PPP packet from 
the data area of the AAL5 protocol data unit as shown in 
FIG. 1(b). 

Lastly, the access server 104 extracts the IP datagram 
from the data area of the PPP packet as shown in FIG. 1(a). 

The access server 104 routes the IP datagram by identi- 
fying the public IP address assigned to the header of the IP 
datagram, converts the IP datagram into the physical frame 
15 format of an output side line, and then transmits it to the 
Internet 105. 

Configuration of the Modem 101> 

FIG. 8 shows the configuration of the modem 101 of FIG. 

2. 

20 As a feature relating to the present invention, the modem 
101 has a capability for transmitting an upstream having a 
predetermined frequency to the DSLAM 102 via an xDSL 
driver 712 when the modem 101 is powered up. The XDSL 
driver 712 powers up the xDSL driver for the corresponding 

25 xDSL line, etc. by detecting this upstream. As a result, a 
waste of electric power can be prevented when no commu- 
nication is made. 

A lOBase-T hub 701 connects a plurality of PCs 106 with 
Ethernet cables. 

30 A PAC (PPTP Access Concentrator) 703, together with a 
PNS (PPTP Network Server) 702 within the PC 106, pro- 
vides a client/server capability for controlling the PPTP 
(Point to Point Tunneling Protocol). 
A PPTP (or L2TP) multiplexing circuit 704 within the 

35 PAC 703 receives an Ethernet frame from the lOBase-T hub 
701, extracts a PPTP (or L2TP) packet as sequentially shown 
in FIGS. 5(e) to 5(b), and passes the extracted packet to a 
PPTP controller 705 corresponding to each PPP session. 
Conversely, the PPTP multiplexing circuit 704 assembles 

40 an Ethernet frame from the PPTP (or L2TP) packet passed 
from each PPTP controller 705 in the order of FIGS. S(b) to 
5(e), multiplexes Ethernet frames, and transmits the multi- 
plexed frame from the lOBase-T hub 701 to the PC 106. 
Next, the PPTP controller 705 within the PAC 703 

45 extracts the PPP packet from the PPTP (or L2TP) packet as 
shown in FIG. 5(a), and passes the extracted packet to a 
corresponding SAR 710 connected to the PPTP controller 
705. 

Conversely, the PPTP controller 705 assembles the PPTP 
50 (or L2TP) packet from the PPP packet passed from the 
corresponding SAR 710 in the order of FIGS. 5(a) to 5(6), 
and passes the assembled packet to the PPTP multiplexing 
circuit 704. 

A BootP server 706 within the PAC 703 assigns to the PC 
55 106 an IP address in private IP addresses which assigned for 
the local network between the PC 106 and the modem 101 
by communicating with a BootP client 714 within the PC 
106, when the PC 106 is connected to the lOBase-T hub 701 
and is booted up. 
60 An IP tunnel/ATM VC negotiator 707 performs conver- 
sion between the IP tunnel link information according to the 
PPTP (or the L2TP) and the ATM VC (ATM Virtual 
Connection) information which is the information about an 
ATM connection, and notifies a Q.2931 processor 709 or the 
65 PPTP controller 705 of the converted information. 

Additionally, the IP tunnel/ATM VC negotiator 707 
receives a transmission speed requested by the controller 
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705, when the PPTP controller 705 connected to the IP 
tunnel/ATM VC negotiator 707 detects the occurrence of the 
IP tunnel request issued from the PC 106. The IP tunnel/ 
ATM VC negotiator 707 then arbitrates whether or not to 
accept the requested transfer speed by making an inquiry to 5 
a resource manager 708 which manages the bandwidth of an 
xDSL line, and feeds back the transfer speed determined 
based on the result of the arbitration to the PPTP controller 
705. 

The Q.2931 processor 709 performs the control of 
connecting/disconnecting an AIM VC between the DSLAM 
102 and the modem 101 itself according to the ITU-T 
Q.2931 signaling procedures. When an ATM VC request is 
issued, a VPI (Virtual Path Identifler)/VCI (Virtual Channel 
Identifier) for an ATM VC is assigned from the DSLAM 
102. Therefore, the Q.2931 processor 709 sets the assigned 15 
VPI/VCI to the SAR (Segmentation And Reassembly unit) 
710. 

The SAR 710 assembles an ATM cell from the PPP packet 
passed from the PPTP controller 705 to which the SAR 710 
, is connected in the order of FIGS. 6(a), to 6(c), assigns the 20 
VPI/VCI notified from the Q.2931 processor 709 to the 
header of the assembled ATM cell, and passes the ATM cell 
to a cell multiplexing circuit 711. 

Conversely, the SAR 710 assembles a PPP packet from 
the ATM cell passed form the cell multiplexing circuit 711 25 
in the order of FIGS. 6(c) to 6(a), and passes the assembled 
packet to the PPTP controller 705 to which the correspond- 
ing SAR 710 is connected. 

The cell multiplexing circuit 711 multiplexes the ATM 
cells passed from a plurality of SARs 710, and passes the 30 
multiplexed cell to an xDSL driver 712. 

Conversely, the cell multiplexing circuit 711 demulti- 
plexes each ATM cell corresponding to each of the plurality 
of SARs 710 from the ATM cell group passed from the 
xDSL driver 712, and passes the demultiplexed ATM cell to 35 
each corresponding SAR 710. 

The xDSL driver 712 modulates the multiplexed signal 
passed from the cell multiplexing circuit 711, and transmits 
the resultant xDSL signal to a subscriber line which is an 
xDSL line. 40 

Conversely, the xDSL driver 712 receives the xDSL 
signal from the subscriber line, demodulates the xDSL 
signal, and passes the resultant multiplexed signal to the cell 
multiplexing circuit 711. 

A rate controller 713 detects the bandwidth used by the 45 
xDSL line and controls the bandwidth for the xDSL line. The 
bandwidth control state is managed by the resource manager 
708. 

Configuration of the DSLAM 102> 

FIG. 9 shows the configuration of the DSLAM 102 50 
illustrated in FIG. 2. 

As a capability which particularly relates to the present 
invention, a frequency detector 802 detects an upstream 
having a predetermined frequency on a subscriber line 
which is an xDSL line via a hybrid circuit 801 to which the 55 
frequency detector 802 is connected. When the frequency 
detector 802 detects this upstream, a power controller 803 
connected to the frequency detector 802 powers up an xDSL 
driver 804 and an SVC Cont. 807, which are connected to 
the power controller 803. As a result, a waste of electric 60 
power can be prevented when no communication is made. 

The DSLAM 102 comprises a plurality of ports, each of 
which is configured by the respective circuits 801 through 
805 and 807 through 809 in correspondence with each 
subscriber line which is an xDSL line. 65 

In each of the plurality of ports, the xDSL driver 804 
extracts an ATM cell by demodulating the xDSL signal 
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received from the hybrid circuit 801 to which the xDSL 
driver 804 and a subscriber line is connected, and transfers 
the extracted ATM cell to an ATR 809 via a UPC (Usage 
Parameter Controller) 808. 

Conversely, the xDSL driver 804 generates an xDSL 
signal by modulating the ATM cell transmitted from the ATR 
809 via the UPC 808, and transmits the generated signal to 
the subscriber line via the hybrid circuit 801 to which the 
xDSL driver 804 is connected. 

The rate controller 805 detects the bandwidth used by the 
XDSL line and controls the bandwidth for the xDSL line via 
the XDSL driver 804. The bandwidth control state is man- 
aged by a resource manager 806. The resource manager 806 
also manages the use state of each ATM VC bandwidth by 
monitoring each buffer within an ATM matrix 810. 

The UPC 808 performs usage parameter control for an 
ATM cell. Since this control does not particularly relate to 
the present invention, its details are omitted. 

An SVC Cont. (SVC controller) 807 is a component 
which particularly relates to the present invention , and 
comprehensively controls the connection/disconnection of 
an ATM VC within the PVC (to be described later) estab- 
lished between the access server 104 and the DSLAM 102 
itself. Its details will be described later. 

An ATR (Address Translator) 809 performs a mutual 
rewrite operation between the VPI/VCI of the header of the 
ATM cell input/output to/from the ATM matrix 810 and the 
VPI/VCI of the header of the ATM cell input/output to/from 
the UPC 808. The VPIs/VCIs between which the rewrite 
operation is performed form a single ATM VC. 

As will be described later, the ATM matrix 810 then 
connects to the ATR 809 connected to the SVC Cont. 807 the 
ATM cell having the VPI/VCI corresponding to the ATM 
VC, which is input/output to/from the SONET interface 
circuit 811 leading to the ATM switch 103, after one ATM 
VC is determined between the SVC Cont .807 within the port 
accommodating the subscriber line and a Con.Mgr. 902 
within the access server 104 which is a connection destina- 
tion based on an ATM VC request issued from the subscriber 
line side, after one ATM VC is determined. 

Additionally, the ATM matrix 810 copies an OAM 
(Operation Administration and Maintenance) cell which is a 
control cell input from each SONET interface circuit 811 
and will be described later within the ATM matrix 810 itself, 
outputs the copied cell to the ATRs 809 within all of the 
ports, and makes the cell reach the SVC Cont. 807 connected 
to each of the ATRs 809. 

Conversely, the ATM matrix 810 copies the OAM cell 
output from the SVC Cont. 807 within each of the ports via 
the ATR 809, and outputs the copied cell to all of the SONET 
interface circuits 811. 

The SONET interface circuits 811 are connected to the 
ATM switch 103 shown in FIG. 2. 

A PVC (Permanent Virtual Connection/Channel) is estab- 
lished beforehand between the access server 104 (shown in 
FIG. 2) and the SONET interface circuit 811 within the 
DSLAM 102 which is reachable therefrom. For example, a 
predetermined VPI value and a predetermined range (or 
arbitrary) VCI value are assigned to this PVC. The ATM cell 
where the predetermined VPI value and the predetermined 
range (or arbitrary) VCI value are assigned to its header is 
transmitted from the SONET interface circuit 811, and is 
then fixedly transferred to the access server 104 by the ATM 
switch 103 (shown in FIG. 2). Also the reverse direction is 
the same. That is, the access server 104 and the DSLAM 102 
are continuously connected, and the ATM switch 103 
(shown in FIG. 2) therefore needs not perform the 
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connection/disconnection procedures between the access 
server 104 and the DSLAM 102. 

As described above, a PVC is established beforehand 
between the DSLAM 102 and the access server 104 accord- 
ing to the preferred embodiment of the present invention. In 
other words, a predetermined number of ATM VCs (VCI 
connections) and a predetermined communications band- 
width are secured beforehand between the DSLAM 102 and 
the access server 104. 

Additionally, according to the preferred embodiment of 
the present invention, the procedure for establishing a con- 
nection is performed by using OAM cells between the SVC 
Cont.807 of the port which accommodates a subscriber line 
and is included in the DSLAM 102, and the Con.Mgr. 902 
included in the access server 104 which is a connection 
destination, based on the ATM VC request issued from the 
subscriber line side, so that a single ATM VC (that is, a pair 
of a VPI and a VCI) within the PVC is allocated between the 
modem 101 connected to the subscribe line and the access 
server 104. As a result, it becomes possible to make a 
communication between the PC 106 connected to the 
modem 101 and the access server 104. When the commu- 
nication between the PC 106 and the access server 104 is 
completed, this ATM VC is released. 

In this case, the number of ATM VCs (the number of 
VCIs) and the communication bandwidth, which are secured 
for the PVC beforehand, may be much smaller than those 
required in the case where all of the modems 101 connected 
to the DSLAM 102 having the PVC simultaneously com- 
municate with the access servers 104 corresponding to the 
PVC. (For example, one-fifth to one-tenth or so). This is 
because the number of general home users who can possibly 
and simultaneously make communications is statistically 
equal to or less than one-fifth to one-tenth of the total 
number of the users. 

Additionally, the DSLAM 102 and the access server 104 
are continuously connected by the above described PVC, 
whereby connection control can be significantly simplified 
and also the response performance can be improved in 
comparison with the case where the DSLAM 102 and the 
access server 104 are connected by an SVC for each call. 
Furthermore, the control of establishing/releasing an ATM 
VC within the PVC can be efficiently performed with the 
control using an idle VC indication cell and a nominated VC 
map, which relates to the present invention and will be 
described later. 

Configuration of the Access Server 104> 

FIG. 10 is a block diagram showing the configuration of 
the access server 104 on the ISP side, which is shown in FIG. 
2. 

A SONET interface circuit 901 is connected to the ATM 
switch 103 shown in FIG. 2. 

As described above, a PVC is established beforehand 
between the SONET interface circuit 901 and the SONET 
interface circuit 811 within the DSLAM 102, which is 
reachable therefrom. 

A Con.Mgr (Connection Manager) 902 is a portion which 
particularly relates to the present invention, and performs the 
entire control of connecting/disconnecting an ATM VC 
within a PVC (to be described later) established between the 
DSLAM 102 and the access server 104 itself. Its details will 
be described later. 

An SAR 903 assembles an IP datagram from the ATM cell 
passed from the Con.Mgr. 902 connected to the SAR 903 in 
the order of FIGS. 7(d) to 7(a), and passes the assembled IP 
datagram to an IP router 904. 

Conversely, the SAR 903 assembles an ATM cell from the 
IP datagram passed from the IP router 904 in the order of 
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FIGS. 7(a) to 7(d), and passes the assembled cell to the 
Con.Mgr. 902 to which the SAR 903 is connected. 

The IP router 904 routes the IP datagram by identifying 
the public IP address specified in the header of the IP 
datagram passed from the SAR 903, converts the IP data- 
gram into the physical frame format of the output side line, 
and transmits it to the Internet 105. 

A DHCP (Dynamic Host Configuration Protocol) server 
905 assigns an IP address to a PC 106 with DHCP 
procedures, when it begins to make a PPP communication 
with the PC 106. 

<Details of line Connection Procedures> 

Provided below is the explanation about the details of the 
line connection procedures implemented in the preferred 
embodiment of the present invention, which has the above 
described configuration. 

The start-up operations of an xDSL line when the modem 
101 is powered up were described earlier. 

Namely, the modem 101 transmits an upstream having a 
predetermined frequency to the DSLAM 102 via the xDSL 
driver 712 when power is turned on. 

The frequency detector 802 of the port which accommo- 
dates the subscriber line connected to the modem 101 and is 
included in the DSLAM 102 detects an upstream having a 
predetermined frequency on the subscriber line via the 
hybrid circuit 801 to which the frequency detector 802 is 
connected. When the frequency detector 802 detects this 
upstream, the power controller 803 connected to the fre- 
quency detector 802 powers up the xDSL driver 804 and the 
SVC Cont. 807, which are connected to the power controller 
803. As a result, a waste of electric power can be prevented 
when no communication is made. 

The frequency detector 802 continues to monitor the 
upstream having the predetermined frequency on the sub- 
scriber line via the hybrid circuit 801 to which the frequency 
detector 802 is connected even after the corresponding 
xDSL line is started up. 

If the frequency detector 802 detects a discontinuity of the 
upstream, it determines that the modem 101 is powered 
down. Then, the power controller 803 connected to the 
frequency detector 802 powers down the xDSL driver 804 
and the SVC Cont. 807, which are connected to the power 
controller 803. As a result, a continuous waste of electric 
power can be prevented. 

Provided next is the explanation about the details of the 
line connection procedures implemented in the preferred 
embodiment of the present invention. 

In the preferred embodiment of the present invention, the 
SVC Cont.807 within each port receives an idle VC indi- 
cation cell which is an OAM cell via the ATR 809 and the 
ATM matrix 810, to which the SVC Cont. 807 is connected, 
within the DSLAM 102 shown in FIG. 9. 

The idle VC indication cell is transmitted by the Con.Mgr. 
902 within the access server 104, which is shown in FIG. 10. 
The Con.Mgr. 902 broadcasts to all of the devices within the 
ATM network the VPI/VCI of an ATM VC which is unused 
in the range of the ATM VC belonging to the PVC that the 
Con.Mgr. 902 itself possesses via the SONET interface 
circuit 901 as the idle VC indication cell, at regular time 
intervals (such as at five-minute intervals). 

FIG. U shows the data structure of an OAM cell which 
can form the idle VC indication cell. 

Because the OAM cell is broadcast within an ATM 
network, the value of the VPI/VCI included in a cell header 
may be arbitrary (it is ignored). Additionally, the value "111" 
which instructs reference to inside of a payload is assigned 
as a payload type. 
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The payload of the OAM cell stores an AAL5 (ATM 
Adaptation Layer 5) protocol data unit. 

The value "00000001" indicating the idle VC indication 
cell is assigned to the first octet as a cell type identifier. 

The VPI/VCI indicating an ATM VC that the Con.Mgr. 
902 does not currently use is particularly stored in an 
information field as a feature of the idle VC indication cell. 

The idle VC indication cell is received by each SVC Cont. 
807 from the ATM switch 103 (shown in FIG. 2) via the 
SONET interface circuit 811, the ATM matrix 810, and each 
ATR 809, which are included in the DSLAM 102 shown in 
FIG. 9. 

Upon receipt of the idle VC indication cell, the SVC Cont. 
807 extracts the VPI/VCI of the idle ATM VC stored in the 
information field of the cell, and registers the extracted 
VPI/VCI to a nominated VC map possessed by the SVC 
Cont. 807. 

The nominated VC map stores not only the information 
about an idle ATM VC but also the information about the 
ATM VC used by the port to which the map itself currently 
belongs. 

FIG. 12 shows the data structure of the nominated VC 
map. 

This map stores, for each ATM VC, the port number (NW 
Port #) of the SONET interface circuit 811 of the DSLAM 
102 to which an ATM VC belongs, an STS channel number 
(STS CH#) configuring the SONET interface at which the 
SONET interface circuit 811 terminates, the VPI (VPI 
#)/VCI (VCI #) of the ATM VC, an ATM address of the 
access server 104 to which the ATM VC belongs, an 
identifier (ISP ID) of the ISP (Internet Service Provider) that 
manages the access server 104, and the current use status 
(Status) of the ATM VC. A plurality of PCs 106 can be 
connected to the subscriber line accommodated by the port 
to which this map belongs via the modem 101, and each of 
the PCs 106 can individually establish a PPP session with 
the access server 104. Therefore, one ATM address corre- 
sponding to one access server 104 may be assigned to the 
entries of a plurality of ATM VCs in the above described 
map. 

The SVC Cont. 807 within the port corresponding to each 
subscriber line within the DSLAM 102 can continuously 
identify which ATM VC is not used for each access server 
104 by referencing the nominated VC map possessed by the 
SVC Cont, 807. Therefore, a subscriber call can be con- 
nected to an idle ATM VC within the P VC corresponding to 
the access server 104 which is a connection destination 
without confirming an external network management system 
or an upstream device, with the following procedures. 

FIG. 13 shows the sequence for establishing an end-to- 
end connection. 

The operations for powering up the port on the DSLAM 
102 side when the modem 101 is powered up are the same 
as those described above (SI and S2 of FIG. 13). 

Next, an IP tunnel request is issued from the PC 106 
(shown in FIG. 2) to the modem 101 (S3 of FIG. 13). 

The details of the IP tunnel request are illustrated in the 
sequence of FIG. 14. The following sequence is based on a 
PPTP. However, the sequence based on an L2TP is similar 
to this sequence. 

First of all, the PNS 702 within the PC 106 issues a start 
control connection request to the PAC 703 (shown in FIG. 
8) within the modem 101 (S3-1 of FIG. 14). This request is 
a PPTP control message for establishing a control connec- 
tion between the PNS 702 and the PAC 703, and has the 
structure shown in FIG. 15. 

In FIG. 15, "Length" is the total data length of the start 
control connection request. "PPTP Message Type" is set to 
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the value "1" indicating the control message. "Magic 
Cookie" is assigned with the code for checking validity. 
"Control Message Type" is assigned with the value "1" 
indicating the start control connection request. All the bits of 
"ReservedO" and "Reservedl" are set to "0". "Protocol 
Version" is assigned with the PPTP version requested by a 
transmitting side. "Framing Capabilities" is assigned with a 
frame type that the transmitting side can provide. "1" is 
assigned for asynchronous framing, while "2" is assigned 
for synchronous framing. "Bearer Capabilities" is assigned 
with the bearer capability that the transmitting side can 
provide. "1" is assigned for an analog access support, while 
"2" is assigned for a digital access support. "Maximum 
Channels" is assigned with the number of PPP sessions that 
the PAC 703 can support. Since this field is assigned by the 
PAC 703, all the bits of this field are set to "0", 

"Firmware Revision" is assigned with the firmware ver- 
sion number of the PNS 702. "Host Name" is assigned with 
the host name of the PNS 702. This host name can be 
identified by a DNS (Domain Name System). "Vendor 
String" is assigned with the vendor name of the PNS 702. 

Upon receipt of the above described start control connec- 
tion request, the PAC 703 returns a start control connection 
reply to the PNS 702 within the PC 106, which transmitted 
the start control connection request (S3-2 of FIG. 14). This 
reply is also a PPTP control message, and has the structure 
shown in FIG. 16. 

The data structure shown in FIG. 16 resembles the data 
structure shown in FIG. 15. However, "Control Message 
Type" is assigned with the value "2" indicating the start 
control connection reply. Additionally, "Result Code" is 
assigned with "1" when a channel is successfully 
established, "2" when a general error occurs, "3" when a 
command channel currently exists, "4" when the request has 
no authority for establishing a command channel, and "5" 
when the protocol version of the request is not supported. 
Furthermore, the details of a problem are displayed only 
when a general error occurs. "Maximum Channels" is 
assigned with the number of PPP sessions that the PAC 703 
can support. "Host Name" is assigned with the DNS host 
name of the PAC 703. 

Upon receipt of the start control connection reply, the 
PNS 702 within the PC 106 transmits "SetLinklnfo" (S3-3). 
The "SetLinklnfo" is a PPTP control message transmitted 
for setting a PPP-arbitrated option, and has the structure 
shown in FIG. 17. 

In FIG. 17, "Length" is the total data length of the 
"SetLinklnfo". "PPTP Message Type" is set to "1" indicat- 
ing the control message. "Magic Cookie" is assigned with 
the code for checking validity. "Control Message Type" is 
set to the value "15" indicating the "SetLinklnfo". All the 
bits of "ReservedO*' and "Reserved 1" are set to "0**. "Peer's 
Call ID" is assigned with a call identifier that the PAC 703 
assigns to this call. "SendACCM" and "ReceiveACCM" are 
respectively assigned with an ACCM that a client uses for 
outgoing and incoming PPP packets. 

Then, the PNS 702 within the PC 106 issues an outgoing 
call request to the PAC 703 within the modem 101 (S3-4). 
This request is a PPTP control message for requesting the 
PAC 703 to originate an external call (access server 104). 
This request includes the information required for originat- 
ing a call and the information for controlling a data transfer. 
It has the structure shown in FIG. 18. 

In FIG. 18, "Length" is the total data length of this 
request. "PPTP Message Type" is set to the value "1" 
indicating the control message. "Magic Cookie" is assigned 
with the code for checking validity. "Control Message Type" 
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is set to the value "7" indicating the outgoing call. All the 
bits of "ReservedO" and "Reserved 1" are set to "0". "Call 
ID" is assigned with an identifier for uniquely identifying a 
pair of the PNS 702 and the PAC 703, that is, an IP tunnel 
"Call Serial Number" is assigned with an identifier for 
identifying this call in log information. "Minimum BPS" 
and "Maximum BPS" are assigned with minimum and 
maximum line speeds (bits per second) which are allowable 
for this session. "Bearer Capabilities" is assigned with a 
bearer capability required for this outgoing call. "1" is 
assigned to the call established on an analog channel, while 
"2" is assigned to the call established on a digital channel. 
"3" is assigned to a call established on whichever channel. 
"Framing Type" is assigned with a PPP frame type. "1" is 
assigned for a call using asynchronous framing, while "2" is 
assigned for a call using synchronous framing. "Packet 
Recv. Window Size" is assigned with the number of received 
data packets that the PNS 702 buffers for this session. 
"Packet Processing Delay" is assigned with the duration of 
a packet processing delay extension of the data to be 
transmitted from the PAC 703 to the PNS 702 in units of 
one-tenth of a second. "Phone Number Length" is assigned 
with the number of digits of a telephone number in a "Phone 
Number" field. "Phone Number" and "Subaddress" are 
assigned with the ATM address of the access server 104. 

Upon receipt of the above described outgoing call request 
from the PC 106, the PPTP controller 705 (shown in FIG. 8) 
which corresponds to the above described call and is 
included in the PAC 703 within the modem 101 passes to the 
Q.2931 processor 709 the "Phone Number" and the "Sub- 
address" of the access server 104, which are extracted from 
the outgoing call request, and passes to the IP tunnel ATM 
VC negotiator 707 the "Minimum BPS" and the "Maximum 
BPS", which are extracted from the request. 

The IP tunnel/ATM VC negotiator 707 shown in FIG. 8 
performs the following control operations in order to prevent 
a congestion occurring on an xDSL line which is UBR 
(Unspecified Bit Rate) controlled. That is, the IP tunnel/ 
ATM VC negotiator 707 converts the minimum BPS and the 
maximum BPS that the above described IP tunnel request 
requires into a minimum cell rate and a maximum cell rate, 
respectively, which are parameters of an ATM VC, and 
compares the converted rates with the bandwidth of the 
XDSL line and the currently unused bandwidth, which are 
received from the resource manager 708. As a result of the 
comparison, if the values of the IP tunnel request are 
unsuitable, the IP tunnel/ATM VC negotiator, 707 requests 
the PPTP controller 705 to change these values. 

When the "Phone Number" and the "Subaddress" of the 
access server 104 are passed from the PPTP controller 705, 
the Q.2931 processor 709 shown in FIG. 8 issues to the 
DSLAM 102 the ATM VC request where the ATM address 
of the access server 104 is specified according to the ITU-T 
Q.2931 signaling procedures (S4 of FIG. 13 or FIG. 14). 

This ATM VC request is converted into an ATM cell for 
UNI (User Network Interface) signaling in the SAR 710 
shown in FIG. 8, and is transmitted to a subscriber line 
which is an xDSL line via the cell multiplexing circuit 711 
and the xDSL driver 712. 

In the DSLAM 102 shown in FIG. 9, upon receipt of the 
above described ATM VC request via the hybrid circuit 801, 
the xDSL driver 804, the UPC 808, and the ATR 809, the 
SVC Cont. 807 searches for an idle VC with the following 
procedures. 

First of all, the SVC Cont. 809 identifies from the ATM 
VC request the ATM address of the access server 104 which 
is the connection destination. 
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The SVC Cont. 807 then searches the ATM VC group 
including the ATM address of the access server 104 in the 
nominated VC map (refer to FIG. 12), and extracts the entry 
of an ATM VC whose current use status is unoccupied, that 

5 is, an idle ATM VC from the searched group. 

When the SVC Cont. 807 successfully extracts the entry 
of the idle ATM VC, it confirms that the VPI/VCI assigned 
to the extracted entry is not used by communicating with the 
Con.Mgr. 902 within the access server 104 which is the 

10 connection destination. 

Specifically, the SVC Cont. 87 transmits a connection 
confirm cell which is an OAM cell (S6 of FIG. 13). This 
OAM cell has the above described data structure shown in 
FIG. 11. The value "00000002" indicating the connection 

15 confirm cell is assigned as the cell type identifier within the 
pay load. Additionally, the ATM address of the access server 
104 which is the connection destination, the VPI/VCI of the 
idle ATM VC, the ATM address of the DSLAM 102, and the 
port number of the SVC Cont. 807 are stored in the 

20 information field. 

The above described connection confirm cell is input from 
the SVC Cont. 807 to the ATM matrix 810 via the ATR 809, 
copied in the ATM matrix 810, and broadcast from all of the 
SONET interface circuits 811 as an OAM cell, in FIG. 9. 

25 When the OAM cell reaches the Con.Mgr 902 (refer to 
FIG. 10) within the access server 104 which is the connec- 
tion destination, the Con.Mgr. 902 identifies that this OAM 
cell is the connection confirm cell addressed to the Con.Mgr. 
902 itself by recognizing the cell type identifier stored in the 

30 payload of the OAM cell and the ATM address of its own 
stored in the information field within the payload. 

The Con.Mgr. 902 then determines whether or not the 
VPI/VCI stored in the information field within the payload 
of that connection confirm cell are not currently used (S7 of 

35 FIG. 13). 

If the Con.Mgr. 902 determines that the VPI/VCI are 
currently unused, it transmits a connection confirm reply cell 
which is an OAM cell (S8 of FIG. 13). This OAM cell has 
the above described data structure shown in FIG. 11, and the 
40 value "00000003" indicating the connection confirm reply 
cell is assigned as the cell type identifier within the payload. 
The contents of the information field of the above described 
connection confirm cell are stored in the information field 
unchanged. 

45 This connection confirm reply cell is broadcast as the 

OAM cell from the Con.Mgr. 902 via the SONET interface 

circuit 901 in FIG. 10 (S8 of FIG. 13). 

When this OAM cell reaches the DSLAM 102 which is 

the connection destination, it is transferred from the SONET 
50 interface circuit 811 to the ATM matrix 810, copied, and 

broadcast to the ATRs 809 within all of the ports shown in 

FIG. 9. 

Upon receipt of the OAM cell via the ATR 809, the SVC 
Cont. 807 which transmitted the connection confirm cell 
55 identifies that this OAM cell is the connection confirm reply 
cell addressed to the SVC Cont. 807 itself by recognizing the 
cell type identifier stored in the payload of the OAM cell and 
its own ATM address stored in the information field within 
the payload. 

60 Upon receipt of the connection confirm reply cell, the 
SVC Cont. 807 transmits a connection get cell which is an 
OAM cell to the access server 104 which is the connection 
destination (S9 of FIG. 13). This OAM cell has the above 
described data structure shown in FIG. 11. The value 

65 "00000004" indicating the connection get cell is assigned as 
the cell type identifier within the payload. The ATM address 
of the access server 104 which is the connection destination, 
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the VPI/VCI of the idle ATM VC, the ATM address of the 
DSLAM 102, and the port number of the SVC Cont. 807 are 
stored in the information field. 

Additionally, the SVC Cont. 807 changes the use status of 
the corresponding entry in the nominated VC map to the 
occupied status on a predetermined cycle. 

Furthermore, the SVC Cont. 807 controls the ATM matrix 
810, and connects the SONET interface circuit 811 which 
can reach the access server 104 which is a connection 
destination, and the ATR 809 to which the above described 
SVC Cont. 807 is connected for the ATM cell with the 
obtained VPI/VCI of the ATM VC. 

Hie above described connection get cell is received and 
identified by the Con. Mgr. 902 within the access server 104 
which is the connection destination in a similar manner as in 
the case of the connection confirm cell. 

Thereafter, the Con.Mgr. 902 does not transmit an idle VC 
indication cell for the VPI/VCI specified as the connection 
get cell. 

Upon receipt of the connection confirm reply cell, the 
SVC Cont. 807 first notifies the modem 101 that issued the 
ATM VC request of a local VPI/VCI along with the estab- 
lishment of the connection with the Q.2931 signaling pro- 
cedures (S10 of FIG. 13 or 14). 

Simultaneously, the SVC Cont. 807 maps the local VPI/ 
VCI and the VPI/VCI of the idle ATM VC identified for the 
access server in the table within the ATR 809. As a result, the 
modem 101 and the access server 104 are connected. 

In FIG. 8, upon receipt of the above described notification 
from the DSLAM 102, the Q.2931 processor 709 within the 
modem 101 notifies the PPTP controller 705 via the IP 
tunnel/ATM VC negotiator 707 that the connection is made. 

As a result, the PPTP controller 705 returns an outgoing 
call reply to the PNS 702 within the PC 106 (Sll of FIG. 13 
or 14). This reply is a PPTP control message similar to an 
outgoing call request, and has the structure shown in FIG. 
19. 

Specifically, the PPTP controller 705 sets the arbitration 
result of the line speed request value notified from the IP 
tunnel/ATM VC negotiator 707 to "Connect Speed". 

In FIG. 19, "Control Message Type" is set to the value "8" 
indicating the outgoing call reply. "Call ID" is assigned with 
the identifier for uniquely identifying a pair of the PNS 702 
and the PAC 703, that, is an IP tunnel. "Peer's Call ID" is set 
to the same value as that of the "Call ID" (refer to FIG. 18) 
set to the outgoing call request. "Result Code" is assigned 
with the result of the outgoing call request. Namely, "1" is 
assigned when a call is established. "2" is assigned when a 
general error occurs. "3" is assigned when no carrier is 
extracted. "4" is assigned when a line is busy. "5" is assigned 
when there is no dial tone. "6" is assigned when a timeout 
occurs. "7" is assigned when a call is rejected. Additionally, 
the details of a problem are displayed only when a general 
error occurs. "Cause Code" is assigned with a further 
detailed cause code. "Connect Speed" is assigned with a line 
speed which is an arbitration result from the IP tunnel/ATM 
VC negotiator 707, as described above. "Packet Recv. 
Window Size" is assigned with the number of received data 
packets that the PNS 702 buffers for this session. "Packet 
Processing Delay" is assigned with a packet processing 
delay extension for the data transmitted from the PAC 703 
to the PNS 702 in units of one-tenth of a second. "Physical 
Channel ID" is information depending on a vendor, and is 
"don't care" in this specification. 

The PNS 702 within the PC 106 receives the above 
described outgoing call reply, so that an IP tunnel is estab- 
lished and a PPP communication is started (S12 of FIG. 13). 
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Then, an IP address request is transmitted from the PC 
106 to the DHCP server 905 within the access server 104 
which is the connection destination (S13 of FIG. 13), and an 
IP address is assigned from the DHCP server 905 to the PC 
5 106 in response to this request. At this time, the Con.Mgr. 
902 changes the PPP setting (S15 of FIG. 13). 

In this way, a PPP session is established between the PC 
106 and the IP router 904 within the access server 104 (S16 
of FIG. 13). Thereafter, it becomes possible to access the 
10 Internet 105 with the above described IP address. 

The access server 104 includes the correspondence table 
between a PPP session ID and the VPI/VCI of an ATM VC 
which transfers a PPP packet. 

FIGS. 20 and 21 show the lists of OAM cells which are 
15 used or can be possibly used in the preferred embodiment 
according to the present invention, and explain the respec- 
tive OAM cells. 

<Details of Line Termination Procedures> 

Provided first is the explanation about the operations 
20 when a line terminating request is received from the modem 
101. 

At first, the SVC Cont. 807 within the DSLAM 102 
receives a call terminating request conforming to the Q.2931 
signaling procedures from an opposing modem 101. 

25 The SVC Cont. 807 cancels the mapping of the corre- 
sponding VPI/VCI in the ATR 809 according to the call 
terminating request. 

Additionally, the SVC Cont. 807 restores the use status of 
the entry corresponding to the VPI/VCI to the unoccupied 

30 status in the nominated VC map on a predetermined cycle. 
Furthermore, the SVC Cont. 807 transmits a connection 
release cell which is an OAM cell. This OAM cell has the 
above described data structure shown in FIG. 11 . The value 
"00000005" indicating the connection confirm cell is 

35 assigned as the cell type identifier of the payload. The ATM 
address of the access server 104 which is a connection 
destination, the VPI/VCI of the ATM VC corresponding to 
the call terminating request, the ATM address of the 
DSLAM 102, and the port number of the SVC Cont. 807 are 

40 stored in the information field. 

The above described connection release cell is input from 
the SVC Cont. 807 to the ATM matrix 810 via the ATR 809, 
copied, and broadcast as th e OAM cell from all of the 
SONET interface circuits 811, in FIG. 8. 

45 When the OAM cell reaches the Con.Mgr. 902 (refer to 
FIG. 10) within the access server 104 which is the connec- 
tion destination, the Con.Mgr. 902 identifies that this OAM 
cell is a connection release cell addressed to the Con.Mgr. 
902 itself by recognizing the cell type identifier stored in the 

50 payload of the OAM cell and its own ATM address stored in 
the information field within the payload. 

The Con.Mgr. 902 then resumes the transmission of the 
idle VC indication cell for the VPI/VCI stored in the 
information field within the payload of the connection 

55 release cell. 

<Call Termination Process Due to Power-Off of the Modem 
101> 

For example, if the power of the modem 101 is shut off, 
an xDSL line is terminated from a subscriber side without 

60 the issuance of the call terminating request. If this state is left 
unattended, this call will remain without being released. 

Therefore, according to the present invention, when the 
frequency detector 802 detects the discontinuity of an 
upstream on a subscriber line after an xDSL line is started 

65 up, the power controller 803 connected to the frequency 
detector 802 can be configured to perform the above 
described call termination process for the SVC Cont. 807 
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immediately before the xDSL driver 804 and the SVC Cont. 
807, which are connected to the power controller 803, are 
powered down. 

<Call Termination Process Due to an IP Tunnel Disconnec- 
tion 5 

For example, if the power of the PC 106 is shut off, a line 
is terminated without the termination of an IP tunnel. If this 
state is left unattended, this call remains without being 
released as long as the power of the modem 101 is ON. 

Therefore, according to the present invention, it can be 
configured that the PPTP controller 705 detects the discon- 
nection of an IP tunnel, for example, by detecting the 
discontinuity of an echo message based on the PPTP, and the 
Q.2931 processor 709 issues a call terminating request when 
the disconnection is detected, in the modem 101 shown in 
FIG. 8. 15 
<Prevention of Improper Operations for Establishing an 
ATM VC Performed by the SVC Cont. 807 and the Con. 
Mgr. 902> 

According to the above described preferred embodiment 
of the present invention, the idle VC indication cell is 20 
configured to be transmitted at regular time intervals (such 
as at 5-minute intervals) from the Con. Mgr. 902 in order to 
prevent network resources from being wasted, by utilizing 
transmission of a cell depending on need. 

However, the idle VC indication cell may be configured 15 
to be continuously transmitted as a method for avoiding a 
collision. In this case, there is no need to perform the 
confirmation procedure using a connection confirm cell and 
a connection confirm reply cell. 

incorporating the OAM Cell Termination Capability into a 3Q 
Network Interface Device> 

If DSLAMs 102 are connected as a ring, an OAM cell 
must be configured not to return to an original DSLAM 102. 

In this case, the OAM cell termination capability may be 
incorporated into a network interface device such as a 35 
SONET interface circuit, etc. as an option. 
<Method for Automatically Setting a Nominated VC Map> 

The SVC Cont. 807 can extract the ATM address of the 
ISP to which an idle ATM VC is allocated, by storing the 
ATM address of the access server 104 that transmitted an 4Q 
idle indication cell in the payload of the cell, and can add the 
nominated VC map of the SVC Cont. 807 itself based on this 
data. 

What is claimed is: 

1. An SVC accessing method for use in an ATM-DSLAM, 45 
with which a subscriber side terminating device accesses an 
access server connected to a cell switch network by using a 
fixed-length cell via an accommodation station side termi- 
nating device accommodating a subscriber line to which the 
subscriber side terminating device is connected, comprising: 5Q 
continuously connecting the access server and the accom- 
modation station terminating device with a permanent 
virtual connection; 
managing an unused virtual connection within the per- 
manent virtual connection in the access server and the 55 
accommodation station side terminating device; 
allocating an unused virtual connection to the subscriber 
side terminating device by communicating with the 
access server based on a call originating request issued 
from the subscriber side terminating device, in the eo 
accommodation station side terminating device; 
managing an unused virtual connection within the per- 
manent virtual connection while exchanging informa- 
tion about the unused virtual connection by using a 
management and maintenance broadcast cell at prede- 65 
termined time intervals, in the access server and the 
accommodation station side terminating device; and 
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allocating an unused virtual connection to the subscriber 
side terminating device by communicating with the 
access server by using a management and maintenance 
broadcast cell based on the call originating request 
issued from the subscriber side terminating device, in 
the accommodation station side terminating device. 

2. The SVC accessing method according to claim 1, 
further comprising: 

storing identification information of the access server 
along with information about the unused virtual con- 
nection in the management and maintenance broadcast 
cell. 

3. The SVC accessing method according to claim 1, 
further comprising: 

releasing a virtual connection under a communication by 
communicating with the access server with a manage- 
ment and maintenance broadcast cell based on a call 
terminating request issued from the subscriber side 
terminating device, in the accommodation station side 
terminating device. 

4. An SVC accessing method for use in an ATM-DSLAM, 
with which a subscriber side modem which performs 
modulation/demodulation with a digital subscriber line 
method accesses an access server connected to an ATM 
switch network by using an ATM cell transferred with an 
asynchronous transfer mode method via an accommodation 
station side modem accommodating a digital subscriber line 
to which the subscriber side modem is connected, compris- 
ing: 

continuously connecting the access server and the accom- 
modation station side modem with a permanent virtual 
connection; 

managing an unused virtual connection within the per- 
manent virtual connection in the access server and the 
accommodation station side modem; 

allocating an unused virtual connection to the subscriber 
side modem by communicating with the access server 
based on a call originating request issued from the 
subscriber side modem, in the accommodation station 
side modem; 

managing an unused virtual connection within the per- 
manent virtual connection while exchanging informa- 
tion about the unused virtual connection by using a 
management and maintenance broadcast cell, in the 
access server and the accommodation station side 
modem; and 

allocating an unused virtual connection to the subscriber 
side modem by communicating with the access server 
with a management and maintenance broadcast cell 
based on the call originating request issued from the 
subscriber side modem, in the accommodation station 
modem. 

5. The SVC accessing method according to claim 4, 
further comprising: 

selectively running a capability for terminating the man- 
agement and maintenance broadcast cell input from a 
network side in an accommodation station side network 
interface. 

6. The SVC accessing method according to claim 4, 
further comprising: 

storing identification information of the access server 
along with information about the unused virtual con- 
nection in the management and maintenance broadcast 
cell. 

7. The SVC accessing method according to claim 6, 
further comprising: 
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selectively running a capability for terminating the man- 
agement and maintenance broadcast cell input from a 
network side in an accommodation station side network 
interface. 

8. The SVC accessing method according to claim 4, 
further comprising: 

releasing a virtual connection under a communication by 
communicating with the access server with a manage- 
ment and maintenance broadcast cell based on a call 
terminating request issued from the subscriber side 
modem, in the accommodation station side modem. 

9. An ATM-DSLAM device, which is an accommodation 
station side modem, for use in a system where a subscriber 
side modem performing modulation/demodulation with a 
digital subscriber line method accesses an access server 
connected to an ATM switch network by using an ATM cell 
transferred with an asynchronous transfer mode method via 
the accommodation station side modem accommodating a 
digital subscriber line to which the subscriber side modem is 
connected, comprising: 

a connecting device for making a continuous connection 
with the access server by using a permanent virtual 
connection; 

a connection managing device for managing an unused 
virtual connection within the permanent virtual con- 
nection; and 

a connection allocating device for allocating an unused 
virtual connection to the subscriber side modem by 
communicating with the access server based on a call 
originating request issued from the subscriber side 
modem; wherein 

said connection managing device manages an unused 
virtual connection within the permanent virtual con- 
nection while exchanging with the access server 
information about the unused virtual connection by 
using a management and maintenance broadcast cell; 
and 

said connection allocating device allocates an unused 
virtual connection to the subscriber side modem by 
communicating with the access server with a man- 
agement and maintenance broadcast cell based on a 
call originating request issued from the subscriber 
side modem. 

10. The ATM-DSLAM device according to claim 9, 
further comprising: 

a network interface for selectively performing a capability 
for terminating the management and maintenance 
broadcast cell input from a network side. 

11. The ATM-DSLAM device according to claim 9, 
wherein identification information of the access server is 
stored in the management and maintenance broadcast cell 
along with information about the unused virtual connection. 

12. The ATM-DSLAM device according to claim 9, 
wherein said connection allocating device releases a virtual 
connection under a communication by communicating with 
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the access server with the management and maintenance 
broadcast cell based on a call terminating request issued 
from the subscriber side modem. 

13. An ATM access server module which is an access 
server for use in a system where a subscriber side modem 
performing modulation/demodulation with a digital sub- 
scriber line method accesses the access server connected to 
an ATM switch network by using an ATM cell transferred 
with an asynchronous transfer mode method via an accom- 
modation station side modem accommodating a digital 
subscriber line to which the subscriber side modem is 
connected, comprising: 

a connecting device for making a continuous connection 
with the accommodation station side modem by using 
a permanent virtual connection; and 

a connection managing device for managing an unused 
virtual connection within the permanent virtual con- 
nection; wherein 

said connection managing device manages the unused 
virtual connection within the permanent virtual con- 
nection while exchanging with the accommodation 
station side modem information about the unused 
virtual connection by using a management and main- 
tenance broadcast cell, and wherein 

an unused virtual connection is allocated to the sub- 
scriber side modem through communication with the 
accommodation station side modem with a manage- 
ment and maintenance broadcast cell based on a call 
originating request issued from the subscriber side 
modem. 

14. An ATM modem which is a subscriber side modem for 
use in a system where the subscriber side modem perform- 
ing modulation/demodulation with a digital subscriber line 
method accesses an access server connected to an ATM 
switch network by using an ATM cell transferred with an 
asynchronous transfer mode method via an accommodation 
station side modem accommodating a digital subscriber line 
to which the subscriber side modem is connected, and the 
accommodation station side modem continuously connected 
with the access server by using a permanent virtual connec- 
tion and managing an unused virtual connection within the 
permanent virtual connection, comprising: 

a connection allocation receiving device for receiving an 
allocation of an unused virtual connection, within the 
permanent virtual connection, from the accommoda- 
tion station side modem by issuing a call originating 
request to the accommodation station side modem; 
wherein 

said connection allocating receiving device allocates an 
unused virtual connection to the subscriber side 
modem by communicating with the access server 
with a management and maintenance broadcast cell 
based on a call originating request issued from the 
subscriber side modem. 
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